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1.  Background 

Formulated  in  the  late  1970s  to  specify  the  require¬ 
ments  of  the  Operational  Flight  Program  (OFP)  of  the 
A- 7  aircraft  [8],  the  SCR  (Software  Cost  Reduction) 
requirements  method  is  a  method  based  on  tables  for 
specifying  the  requirements  of  software  systems.  Dur¬ 
ing  the  1980s  and  the  early  1990s,  many  companies,  in¬ 
cluding  Bell  Laboratories,  Grumman,  Ontario  Hydro, 
and  Lockheed,  applied  the  SCR  requirements  method 
to  practical  systems.  Each  of  these  applications  of  SCR 
had,  at  most,  weak  tool  support.  To  provide  powerful, 
robust  tool  support  customized  for  the  SCR  method, 
we  have  developed  the  SCR*  toolset.  To  provide  formal 
underpinnings  for  the  method,  we  have  also  developed 
a  formal  model  which  defines  the  semantics  of  SCR 
requirements  specifications. 

2.  The  SCR  Requirements  Model 

In  SCR,  monitored  and  controlled  variables  represent 
environmental  quantities  that  the  system  monitors  and 
controls  [7].  The  environment  nondeterministically 
produces  a  sequence  of  input  events,  where  an  input 
event  is  a  change  in  some  monitored  quantity.  The 
system  responds  to  each  input  event  in  turn  by  chang¬ 
ing  state  and  possibly  changing  one  or  more  controlled 
quantities. 

The  SCR  formal  model,  a  special  case  of  the  classic 
state  machine  model,  represents  a  system  as  a  4-tuple, 
(S',  So, Em ,T),  where  S  is  a  set  of  states,  So  C  S  is 
the  initial  state  set,  Em  is  the  set  of  input  events,  and 
T  is  a  function  describing  the  allowed  state  transitions 
[7].  T  is  a  composition  of  simpler  functions  derived 
from  the  tables  in  an  SCR  specification.  The  formal 
model  requires  each  table  to  satisfy  certain  properties. 
These  properties  guarantee  that  each  table  describes 
a  total  function.  To  specify  the  system  requirements 
concisely,  the  SCR  method  uses  mode  classes,  condi¬ 
tions,  and  events.  A  mode  class  organizes  the  system 
states  into  equivalence  classes,  each  called  a  mode.  The 
SCR  model  includes  a  set  RF  containing  the  names  of 


all  variables  (e.g.,  monitored  and  controlled  variables, 
mode  classes)  in  a  given  specification  and  a  type  func¬ 
tion  TY  mapping  each  variable  in  RF  to  a  set  of  val¬ 
ues.  In  the  model,  a  state  is  a  function  mapping  each 
variable  r  in  RF  to  its  value  in  TY(r),  a  condition  is  a 
predicate  defined  on  a  state,  and  an  event  is  a  predicate 
defined  on  two  states  when  any  state  variable  changes. 

3.  The  SCR  Tools 

SCR*  is  an  integrated  suite  of  tools  supporting  the 
SCR  requirements  method.  It  includes  a  specification 
editor  for  creating  a  requirements  specification,  a  de¬ 
pendency  graph  browser  for  displaying  the  variable  de¬ 
pendencies,  a  consistency  checker  for  detecting  well- 
formedness  errors  (e.g.,  missing  cases),  a  simulator  for 
validating  the  specification,  a  model  checker  and  the¬ 
orem  prover  for  checking  application  properties,  and 
an  invariant  generator  for  automatically  constructing 
state  invariants  from  the  SCR  tables. 

Specification  Editor.  To  create  and  modify  a  re¬ 
quirements  specification,  the  user  invokes  the  speci¬ 
fication  editor  [4].  Each  SCR  specification  is  orga¬ 
nized  into  dictionaries  and  tables.  The  dictionaries  de¬ 
fine  the  static  information  in  the  specification,  such  as 
the  names  and  values  of  variables  and  the  user-defined 
types.  The  tables  specify  how  the  variables  change  in 
response  to  input  events.  Eaej 

Dependency  Graph  Browser.  Understanding  the 
relationship  between  different  parts  of  a  large  specifi¬ 
cation  can  be  difficult.  To  address  this  problem,  the 
Dependency  Graph  Browser  (DGB)  represents  the  de¬ 
pendencies  among  the  variables  in  a  given  SCR  specifi¬ 
cation  as  a  directed  graph  [6].  By  studying  the  graph, 
a  user  can  detect  errors  such  as  undefined  variables 
and  circular  definitions.  He  can  also  use  the  DGB  to 
extract  and  analyze  subsets  of  the  dependency  graph, 
e.g.,  the  subgraph  containing  all  variables  upon  which 
a  selected  controlled  variable  depends. 

Consistency  Checker.  The  consistency  checker  [7,  6] 
analyzes  a  specification  for  consistency  with  the  SCR 
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requirements  model.  It  exposes  syntax  and  type  er¬ 
rors,  variable  name  discrepancies,  missing  cases,  non¬ 
determinism,  and  circular  definitions.  When  an  er¬ 
ror  is  detected,  the  consistency  checker  provides  de¬ 
tailed  feedback  to  facilitate  error  correction.  A  form  of 
static  analysis,  consistency  checking  avoids  executing 
the  specification  and  reachability  analysis.  In  develop¬ 
ing  an  SCR  specification,  the  user  normally  invokes  the 
consistency  checker  first  and  postpones  more  expensive 
analysis,  e.g.,  model  checking,  until  later. 

Simulator.  To  validate  a  specification,  the  user  can 
run  the  simulator  [6]  and  analyze  the  results  to  ensure 
that  the  specification  captures  the  intended  behavior. 
Additionally,  the  user  can  define  invariant  properties 
believed  to  be  true  of  the  required  behavior  and,  using 
simulation,  execute  a  series  of  scenarios  to  determine  if 
any  violate  the  invariants.  The  simulator  supports  the 
rapid  construction  of  front-ends,  customized  for  partic¬ 
ular  application  domains.  For  example,  we  have  con¬ 
structed  a  front-end  that  simulates  a  cockpit  display. 
Pilots  can  use  the  simulated  cockpit  display  to  eval¬ 
uate  an  attack  aircraft  specification.  By  interacting 
with  this  display,  the  pilot  moves  out  of  the  world  of 
requirements  specification  and  into  the  world  of  attack 
aircraft,  where  he  is  the  expert.  Such  an  interface  facil¬ 
itates  customer  validation  of  the  specification.  A  sec¬ 
ond  customized  front-end,  part  of  the  weapons  system 
prototype  mentioned  below,  has  also  been  developed. 

Model  Checker.  After  using  SCR*  to  develop  a  re¬ 
quirements  specification,  a  developer  can  invoke  the 
Spin  model  checker  [9]  to  check  properties  of  the  spec¬ 
ification.  Once  a  property  violation  is  detected,  the 
user  can  run  the  simulator  to  demonstrate  and  vali¬ 
date  the  violation.  To  make  model  checking  practical, 
we  have  developed  sound  methods  for  deriving  abstrac¬ 
tions  from  SCR  specifications  [2,  5].  The  methods  are 
practical:  none  requires  ingenuity  on  the  user’s  part, 
and  each  derives  a  smaller,  more  abstract  specification 
automatically.  Based  on  the  property  to  be  analyzed, 
these  methods  eliminate  unneeded  detail  from  the  spec¬ 
ification. 

Theorem  Prover.  When  model  checking  fails  to  re¬ 
veal  an  error  in  a  requirements  specification  or  pro¬ 
duces  many  spurious  counterexamples,  the  user  may 
use  mechanical  theorem  proving  to  establish  the  prop¬ 
erty.  We  have  in  fact  done  this  for  a  small  SCR  specifi¬ 
cation,  using  the  mechanical  prover  in  PVS.  For  details, 
see  [1]. 

Invariant  Generator.  Recently,  a  prototype  tool 
that  automatically  generates  state  invariants  from  SCR 
tables  [10]  was  integrated  into  SCR*.  This  tool  has 
generated  more  than  20  interesting  state  invariants 


from  the  mode  tables  in  a  revised  version  of  the  A-7 
requirements  document. 

4.  Applying  SCR*  to  Practical  Systems. 

To  date,  SCR*  has  been  applied  in  several  pilot 
projects.  In  one  project,  NASA  researchers  used  SCR* 
to  detect  missing  cases  and  nondeterminism  in  the 
prose  software  requirements  specification  of  the  Inter¬ 
national  Space  Station  [3].  In  a  second  project,  Rock¬ 
well  engineers  used  SCR*  to  expose  24  errors,  many 
of  them  serious,  in  the  requirements  specification  of 
a  flight  guidance  system  [11],  Of  the  detected  errors, 
a  third  were  uncovered  in  constructing  the  specifica¬ 
tion,  a  third  by  the  consistency  checker,  and  the  re¬ 
maining  third  with  the  simulator.  In  a  third  project, 
NRL  applied  SCR*  to  a  sizable  contractor-produced  re¬ 
quirements  specification  of  the  Weapons  Control  Panel 
(WCP)  of  a  safety-critical  US  military  system  [5].  The 
tools  uncovered  numerous  errors  in  the  specification, 
including  a  safety  violation.  Translating  the  specifi¬ 
cation  into  the  SCR  tabular  notation,  using  SCR*  to 
detect  errors,  and  building  a  WCP  prototype  required 
only  one  person-month,  thus  demonstrating  the  utility 
and  cost-effectiveness  of  the  SCR  method. 

To  date,  more  than  40  industry  and  government 
organizations  and  30  universities  in  the  US,  the  UK, 
Canada,  and  Germany  are  experimenting  with  SCR*. 
Moreover,  a  growing  number  of  universities  are  incor¬ 
porating  SCR*  into  their  software  engineering  courses. 

5.  Learning  More  About  SCR* 

To  obtain  a  copy  of  the  SCR*  toolset  and 
a  draft  toolset  user  guide,  send  a  request  to 
labaw@itd.nrl.navy.mil.  For  more  information  about 
SCR*,  see  our  web  site  at 

http:/ / www. chacs.itd.nrl.navy.mil /SCR 
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